Problem

A task that completes successfully can be left marked "ongoing" (never "done"), so it appears unfinished even though it produced its answer.

Root cause

On completion the frontend PUTs the run's final answer as summary to /chat/history/{id}, but chat_history.summary is a length-bounded column (varchar(1024)). When the answer exceeds the limit, the server UPDATE fails with psycopg2 StringDataRightTruncation (HTTP 500), which rolls back the whole update -- including the status change to done -- so the row stays ongoing. It is length-dependent, not model-dependent: any answer over the limit triggers it.

Observed: 819/674-char answers saved and completed; 1812/2123-char answers failed and stayed ongoing. Server log: sqlalchemy.exc.DataError: (psycopg2.errors.StringDataRightTruncation) value too long for type character varying(1024).

Fix

Clamp the summary to the column length before it is stored, so an over-long answer can no longer fail the update or block the status change. The full text is unaffected -- it is preserved in the task's end step.

• Frontend: clamp summary in the three /chat/history/{id} PUT payloads through a shared clampHistorySummary helper built on a single MAX_CHAT_HISTORY_SUMMARY_LENGTH constant.
• Server (defensive): clamp summary in update_chat_history so any client's over-long value is truncated rather than rejected. The limit is derived from the column definition (ChatHistory.summary.type.length) instead of a second hardcoded value, so the clamp cannot drift from the schema if the column is ever resized.

Testing

Runs whose final answer exceeds the summary column length now complete and are marked done (previously they stayed ongoing; the failing rows above save correctly with the clamp in place). tsc passes for the changed frontend file; the changed server file compiles, and the column-derived limit was verified to evaluate to the expected value at runtime.